Die berufliche Situation informatisch Handelnder in der ethischen Reflexion

Ausgehend von einer Betrachtung des Einflusses von InformatikerInnen und ihren Handlungsmustern auf Arbeitsprozesse und vor dem Hintergrund einer kritischen Auseinandersetzung mit bisherigen berufsethischen Leitlinien wollen wir einen neuen Ansatz wagen, über Informatik und Verantwortung nachzudenken. Eine Rekonstruktion des Begriffs Verantwortung bietet uns ein reichhaltiges begriffliches Instrumentarium zur Reflexion des Verhältnisses von Verantwortung und informatischer Praxis. Wir plädieren dafür, dass informatisch Handelnde lernen müssen, ethische Probleme zu erkennen, implizite Annahmen von Arbeitskulturen zu durchschauen und ein Bewusstsein für die Veränderbarkeit dieser Arbeitskulturen entwickeln sollten. Zusätzlich bedarf es kollektiver und rechtlicher Veränderungen der Rahmenbedingungen für verantwortliches Handeln. 1. Informatik und Arbeitswelt Heutzutage werden in einem modernen Industriebetrieb fast alle Geschäftsprozesse durch IT-Anwendungen unterstützt. Diese beeinflussen maßgeblich die Arbeitsweisen und -bedingungen von Menschen, die primär nicht im IT-Sektor arbeiten. Gerade kleinere und mittlere Firmen sehen ihre IT-Abteilung als reinen Dienstleister für die Fachabteilungen und IT-Investitionen als reinen Kostenfaktor. Nicht immer ist den Beteiligten bei der Auswahl eines Systems oder der Erstellung der Spezifikation für ein System bewusst, wie weit reichend der Einfluss auf den Arbeitsprozess sein wird. Häufig dauert die Einführung einer Anwendung einschließlich der zugehörenden Prozesse daher länger als deren Entwicklung. Um die Art und den Umfang der einzuführenden IT-Systeme festzulegen, sollten in einer Konzeptionsphase die Geschäftsprozesse und ihr Beitrag zu den Geschäftszielen und -strategien analysiert werden. Die in dieser Phase festgelegte Spezifikation mit den Anforderungen an die IT-Lösung enthält die Beschreibung der Gesamtziele häufig nicht mehr. In der nachfolgenden Implementierungsphase wird eine „Lösung“ entwickelt und * Kontakt: Eva Hornecker, TU Wien, igw, Argentinierstr. 8, A-1040 Wien, [email protected] Beitrag für den Workshop "Ethik in der Informatik – Die Fortschreibung der Ethischen Leitlinien der GI". 33. Jahrestagung der Gesellschaft für Informatik GI e.V., Universität Frankfurt (Main) 2003. GI-Edition Lecture Notes in Informatics (LNI) Bonner Köllen Verlag, Bd. 2, S. 182-187. installiert. Ist in der Konzeptionsphase noch die Fachabteilung der späteren Benutzer beteiligt, hat während der Implementierungsphase häufig die IT-Abteilung die alleinige Verantwortung. Diese Aufspaltung führt zu einer Trennung des originären Kundenproblems von den spezifizierten Anforderungen. Das Risiko dieser Vorgehensweise ist für beide Seiten zweischneidig. Auf Entwicklerseite ist der Verantwortungsbereich klar eingegrenzt, wenn gegen eine fest vereinbarte Spezifikation entwickelt wird. Genügt die Anwendung den Anforderungen der Spezifikation, erfolgt die Abnahme durch den Kunden. Die Entwickler brauchen zudem nur wenige Kenntnisse aus dem Anwendungsbereich des Kunden. Spezifikationsänderungen werden während der Implementierung im Einvernehmen mit der IT-Abteilung entschieden. Die Auswirkungen auf die Arbeitsprozesse werden so meist unzureichend geprüft. Für den Kunden bietet diese Trennung den Vorteil, dass den Entwicklern nicht die gesamte Information des Projektes übergeben werden muss. Er behält so die alleinige Kontrolle über die nicht IT-spezifischen Anteile der Veränderungen. Andererseits hat er das Risiko, dass die Anwendung der Spezifikation genügt, aber von den Anwendern nicht wie erwartet genutzt werden kann, was zu schwer kontrollierbaren Kosten für Nachbesserungen und zur Unzufriedenheit des Kunden führt. Vielfach unterschätzt werden Aufwände für nicht-technische Maßnahmen (Change Management), die Voraussetzung für einen Nutzen auf Kundenseite sind. Der Wunsch, Projekte linear zu planen und mit möglichst berechenbaren Faktoren zu bewerten, fördert die Verfolgung kurzfristiger Ziele, wie Verkürzung von Durchlaufzeiten oder Personaleinsparung. Die abteilungsbezogene und für jeweils kurze Zeiträume erfolgende Gewinnund Verlustrechnung (anstatt Projekte anhand der unternehmensweiten und den kompletten life-cycle eines Produkts betreffenden Kosten und Gewinne zu betrachten) lässt viele für das Unternehmen sinnvolle Maßnahmen für Entscheidungsträger als nicht attraktiv oder sogar karriere-hinderlich erscheinen [An00]. Methoden, dieses Dilemma aufzulösen, werden bereits praktiziert. Dazu gehören Pilotimplementierungen in kleinem Rahmen, um Auswirkungen auf die Unternehmenskultur und Geschäftsziele frühzeitig zu testen. Insbesondere ist eine neue Sicht und Art der Bewertung von Projekten bei InformatikerInnen wie auch beim Kunden erforderlich. Das erfordert zum einen, dass InformatikerInnen lernen, sowohl die Sprache, als auch die Arbeitsumgebung des Kunden zu verstehen und zum anderen die Bereitschaft der Kunden, ihre IT als zentrale Ressource im Unternehmen zu erkennen und – auch bezogen auf das Zusammenspiel mit den Fachabteilungen – zu positionieren. Die Umsetzung dieser Methoden im täglichen Projektgeschäft kann zu Konflikten mit Vorgesetzten oder Kunden führen, deren Bewältigung von jedem Beteiligten Konfliktfähigkeit und die Auseinandersetzung persönlicher Prioritäten mit allgemeinen Wertsetzungen erfordert. Dabei kann eine offene Diskussion unter IT-Professionals den Einzelnen unterstützen, eigene Standpunkte zu klären und erfolgreicher zu vertreten. 2. Verantwortung und Informatik Die weit reichenden Folgen des Technikeinsatzes stellen somit immer wieder die Frage nach der Verantwortung für Entwicklung und Einsatz von Technik. Um hierauf zu reagieren, wurden von vielen (Informatik-)Berufsvereinigungen ethische Leitlinien, Standesoder Berufsethiken formuliert. Diese sollen Orientierung für das professionelle Handeln und Bewertungsmaßstäbe für technische Entscheidungen geben. Ihre Formulierung erzeugt jedoch Zielkonflikte, die nicht zuletzt am Beispiel der Ethischen Leitlinien der Gesellschaft für Informatik (GI) deutlich werden: 1) Allgemeinheit vs. Konkretheit: Das IT-Berufsfeld ist äußerst heterogen und veränderlich. Denning [De01] klassifiziert IT-Berufe in drei Gruppen: IT-spezifisch (Datenbankentwickler, Software-Ingenieure, SW-Ergonomen), IT-intensiv (eCommerce, Multimedia-Design) und IT-unterstützend (Betrieb/Administration von IT-Systemen, WebDesign, Schulung). Verschieden wie die Berufsbilder sind auch deren Anforderungen und die Reichweiten möglicher Folgen des Einsatzes von Informatik-Systemen, abhängig von Schadenshöhe, Anzahl Betroffener und Art des Schadens. Will man einheitliche ethische Leitlinien formulieren, müssen diese notwendig von der Heterogenität der Adressaten abstrahieren. Dann aber finden sich die einzelnen Betroffenen darin nicht mehr wieder, konkrete Hilfestellungen fehlen. Umgekehrt würde eine stärkere Konkretisierung zur Unübersichtlichkeit führen. 2) Moral vs. Recht: Die ethischen Leitlinien zeigen, dass Kodizes oft in Konkurrenz zum Recht treten bzw. nur reformulieren, was bereits juristisch kodifiziert ist. Damit wird die Rolle von ethischen Leitlinien auf die Anerkennung externer Ansprüche nichtmoralischer Natur reduziert. An der Gültigkeit bspw. von arbeitsrechtlichen Regelungen ändert es nichts, ob deren Geltung erneut durch eine ethische Leitlinie bekräftigt wird, sondern allenfalls an deren Wahrnehmung. Einen anderen Weg gehen bspw. die ethischen Grundsätze des Ingenieurberufs des VDI. Hier wird aufgefordert, moralische Grundsätze gegen gesetzliche Regelungen abzuwägen. Fraglich ist jedoch, was Menschen tun sollen, die dabei einen Widerspruch entdecken. Sollen sie Gesetze brechen? Müssen sie dann die Folgen dieser Entscheidung allein tragen? Oder steht hier der Berufsverband ein? 3) Moral vs. Professionalität: Die ethischen Leitlinien – und andere Kodizes auch – erheben Forderungen, die wenig mit Ethik und viel mit Professionalität zu tun haben. So sind Fach-, Sachund juristische Kompetenz Fähigkeiten, ohne die eine sachgerechte Berufsausübung nicht möglich wäre; dies gilt für alle professionell Handelnden. Zudem lassen sich Fach-, Sachund juristische Kompetenz im Wesentlichen an internen Kriterien der Profession messen, die Bezug auf Effizienz und Effektivität des technischen Handelns nehmen und nicht auf externe moralische Ansprüche. 4) Inklusion vs. Exklusion: Angesichts bspw. der wachsenden Open Source-Bewegung ist fraglich, wer Adressaten ethischer Leitlinien sein sollen bzw. können. Will man alle mit IT-Technologie Beschäftigten und Handelnden erreichen, wird das erste Problem nur verschärft. Eine Einschränkung des Geltungsbereichs kann umgekehrt zur Folge haben, dass sich in konkreten Konfliktfällen niemand als verantwortlich sieht. Trotz der möglichen Kritik an den ethischen Leitlinien der GI [Sc01, We02] bleibt festzustellen, dass die zentrale Idee entsprechender Leitlinien und Kodizes – verantwortliches Handeln im professionellen Umfeld – unverzichtbar ist und bleibt. 3. Verantwortung verstehen ... Eine Rekonstruktion des Begriffs Verantwortung entlang seiner historischen Veränderung [vgl. Ba95] liefert uns ein begriffliches Instrumentarium, „Verantwortung“ – bezogen auf das informatische Handeln – berufspraktisch neu zu deuten. Die Idee der Verantwortung ist die spezifische Lösung der europäischen Gesellschaft für das Problem der Zurechnung. Was zugerechnet wird, ist Resultat sozialer Konstruktion und ergibt sich nicht aus der Sache selber. Lösungen der Verantwortungszuschreibung hängen wesentlich von der jeweiligen Struktur und Reichweite menschlichen Handelns ab. Unverzichtbar für die Idee der „Zurechnung als Verantwortung“ ist die Idee menschlicher Freiheit und Autonomie [Ba95, Ir98]. Verantwortlich ist ein Subjekt einer Handlung. Ihm werden (negative) Handlungsfolgen zugerechnet, die kausal mit dem Handeln zusammenhängen. Damit ist stets ein Werturteil verknüpft, durch welches die Zuschreibung erst moralisch wirksam wird. Das Hervorheben bestimmter Handlungen mit negativen Handlungsfolgen soll den Schuldigen zur Verantwortung ziehen. Sanktionen sollen menschliches Handeln in sozial gewünschte Bahnen lenken. Dieses „klassische“ Modell der Verantwortung hat wichtige und notwendige Voraussetzungen: Kausalität, Individualität und eine scharfe Differenz von Mensch und Natur. Die Frage der „gerecht(fertigt)en“ Zurechnung nimmt zur Kausalität noch die Intention des Handelnden und dessen Möglichkeit der Voraussicht der Folgen (Einsicht) in den Blick. In der Nikomachischen Ethik (Aristoteles) ist für die Bewertung der Situation zudem die Freiwilligkeit im Sinne persönlicher Urheberschaft von großer Bedeutung. Mit der Industrialisierung verbindet sich ein grundlegender Wandel in Struktur und Typus menschlichen Handelns. Technischer Fortschritt und intensivierte Arbeitsteilung erschweren die Zurechnung negativer Handlungsfolgen. Erst jetzt wird der Begriff „Verantwortung“ in der ethischen Literatur [Le84, Ni87] relevant, und auch in der öffentlichen Diskussion z.B. über Dampfkessel-Explosionen oder die Verelendung der arbeitenden Bevölkerung wahrnehmbar. Eine Diskussion beginnt, inwieweit der Staat ins private Unternehmertum einzugreifen habe, wenn es um Sicherheit und Wohlergehen der Öffentlichkeit geht [Bu75]. Wer haftet für Schäden aus Systemversagen, wenn „Unglücksfälle“ nicht mehr kausal zugerechnet werden können? Mit der verschuldensunabhängigen Gefährdungshaftung gewinnt man zwar wieder Zugriff auf ein verantwortliches Subjekt, kann aber nicht mehr beabsichtigte von unbeabsichtigten Folgen unterscheiden. Haftung misst sich daran, wie die Gesellschaft mit den aus technischen Risiken entstandenen sozialen Problemen umzugehen gedenkt. Bedeutsam wird eine Verschiebung im Verantwortungsbegriff. Zur klassischen Frage, wer für einen Schaden verantwortlich sei, tritt nun die Frage, „wer für die ordnungsgemäße Erledigung bestimmter Aufgaben verantwortlich ist“ [Ba95]. Handlungssubjekte sind nun verantwortlich für positive Zustände und die reibungslose Erledigung von Aufgaben. Dabei verlangen „verantwortungsvolle“ Aufgaben typischerweise eine hohe Kompetenz und einen gewissen Ermessensspielraum. Für einen positiven Zustand kann man nur dann verantwortlich sein, wenn man kausalen Einfluss auf die entsprechende Sache hat und in einer normativ relevanten Beziehung (durch Auftrag, Selbstverpflichtung oder den besonderen Wert des Objektes) zur Sache steht [Ba95]. Wir dürfen aber nicht eine moralisch gehaltvolle „Verantwortung“ und eine funktional orientierte „Verantwortlichkeit“ gegeneinander ausspielen. 4. ... in berufspraktischer Hinsicht IT-Fachkräfte tragen als Designer technischer Artefakte und Veränderer von Arbeitsumgebungen mindestens eine Teil-Verantwortung für deren Folgen. Die strukturellen Probleme gängiger Praxis in der IT-Industrie schränken allerdings Erkenntniswie Handlungsmöglichkeiten des Einzelnen massiv ein [BH02]. Viele Kunden wiederum können Software nicht bezüglich Sicherheit, Stabilität, Änderbarkeit etc. einschätzen. Oft sehen sie Software nur als Kostenfaktor und neigen dazu, „Schnell+Billig“-Angebote zu akzeptieren. [N02] spricht von jährlich 59 Mrd. US$ Kosten in US-Unternehmen aufgrund mangelnder Qualitätskontrolle bei der Software-Entwicklung. Kunden akzeptierten auch Programme, deren funktionelle Unvollkommenheit bekannt ist. Insgesamt lässt sich sagen, dass die Software-Industrie zwar einen ausnehmend schlechten Ruf hat, dies aber bislang nicht dazu geführt hat, ihr Verantwortung wirksam zuzuschreiben. Wenn Einsicht in die Folgen des Handelns möglich ist, besteht Verantwortung. Diese Einsicht wird bei IT-Fachkräften durch den enormen Zeitdruck [F00] sowie die Unkenntnis des Einsatzbereichs be-/verhindert. Zudem reduziert die Arbeitsteilung in Analyse und Implementierung (siehe Kap. 1) die verfügbare Kontext-Information. Negative Folgen von Designentscheidungen sind nicht absehbar und meist auch nicht intendiert. Ohne Kontakt zu Anwendern und Betroffenen werden nur vorgegebene Anforderungen (z.B. des Managements) realisiert, die häufig nicht den tatsächlichen Problemen des Einsatzkontextes entsprechen. Vieles deutet darauf hin, dass es sich um ein systemisches Problem der Struktur der Organisation von Software-Entwicklung (SE) handelt. Methoden des Partizipativen oder User-Centered Designs sind ein Schritt in die richtige Richtung, aber kein Allheilmittel. Zudem sind sie den meisten Unternehmen noch zu zeitund kostenaufwändig [An00]. Einsicht in die Folgen des eigenen Handelns ist nicht gleichbedeutend mit dem Vorhandensein alternativer Handlungswege [F00, BH02]: Die hochgradige Arbeitsteilung in der Software-Entwicklung begrenzt den Einflussbereich des Einzelnen. Die ökonomischen Interessen des Arbeitgebers bestimmen, was wie gemacht wird. Die rechtlich/vertraglich geforderte Loyalität/Schweigepflicht zum Arbeitgeber schränkt den Handlungsraum weiter ein. Die Verantwortlichkeit für eine termingerechte Fertigstellung oder die Zurückhaltung von Information kann dabei der Verantwortung für das Wohl eines Kunden entgegenstehen. Der kausale Einfluss des Einzelnen ist folglich beschränkt. Jeder Einzelne muss die Verhältnismäßigkeit von eigenem Opfer (persönliche Konsequenzen) und Problem bewerten. Lynch und Kline [LK00] raten dazu, sich Verbündete zu suchen, Argumente und Strategien zu suchen und abzuwägen, eine „Politik der kleinen Schritte“ zu verfolgen. Die meisten ethischen Konflikte seien keine klaren Entweder-Oder Situationen, sondern Resultat langsamer, sich akkumulierender Entscheidungen. Sie richten ihr Augenmerk daher auf den Einfluss der Arbeitskulturen. Diese schränken Handlungsspielräume ein, sind aber selber veränderbar. Wichtiger als einzelne moralische Extremleistungen sind Veränderungen der Arbeitsund Unternehmenskulturen durch die IT-Schaffenden. Informatisch Handelnde müssen lernen, ethische Probleme frühzeitig zu erkennen, kreative Lösungen zu entwickeln, unterstützende Ressourcen zu identifizieren und Arbeitskulturen langsam zu verändern. Strukturelle Probleme (wie Arbeitsbedingungen und Verhalten der IT-Industrie gegenüber Anwendern) verlangen kollektive Vorgehensweisen, rechtliche Regelungen sowie andere Prioritätensetzungen bei Kunden und Herstellern. Hierzu kann eine verstärkte gesellschaftliche Information und Diskussion beitragen. Wir benötigen eine Reflexion unseres Selbstverständnisses, der Denkund Verhaltensmuster informatischer Praxis. Ziel einer Diskussion über Verantwortung sollte zudem die Veränderung von Arbeitsund Unternehmenskulturen sein. Handlungsoptionen ausnutzen zu können, verlangt ein scharfes individuelles Bewusstsein für ihr Vorhandensein sowie etwaige Widerstände. Dieses Bewusstsein wird bislang zuwenig in der Informatik kultiviert. Studierende, denen man Situationen schildert, die moralische Entscheidungen erfordern, erkennen deren Problematik zunächst meist nicht. Daher sollte die Fähigkeit ethischen Urteilsvermögens und moralischer Improvisation kultiviert werden [vgl. Fo99, Nu90]. Gemeint ist die Fähigkeit, situiert zu handeln und dabei dennoch Prinzipien zu folgen. Kultiviert werden sollte eine Kultur des Geschichtenerzählens, die Praktikern Möglichkeiten zur Reflexion des Erlebten und Studierenden Einblicke in die Komplexität der Praxis bietet. „Which facts to take as significant, and which rules and responsibilities, goals and obligations, promises and understandings, to fulfill in what ways – these are inescapably moral matters that practitioners must face all the time.“ [Fo99] Literaturverzeichnis [An00] Anderson, R.: A Conversation with Don Norman and Janice Rohn. In: Interactions, 7 (3) 2000; S. 36-60. [Ba95] Bayertz, K.: Eine kurze Geschichte der Herkunft der Verantwortung. In (Bayertz, K. Hrsg.): Verantwortung: Prinzip oder Problem? Darmstadt: WBG, 1995; S. 3–71. [BH02] Bittner, P.; Hornecker, E.: Responsibility and the Work of IT-Professionals. From Academia to Practice. In (Brunnstein, K.; Berleur, J. Hrsg.): Human Choice and Computers. Boston: Kluwer Academic Publishers, 2002; S. 171-181. [Bu75] Burke, J. G.: Kesselexplosionen und bundesstaatliche Gewalt in den USA. In (Hausen, K.; Rürup, R. Hrsg.): Moderne Technikgeschichte. Köln: Kiepenheuer & Witsch, 1975; S. 314-336. [De01] Denning, P.: Who are we? In: Communications of the ACM, 44 (2) 2001; S. 15-19. [F00] FIfF-Kommunikation (1)2000, Schwerpunktheft „Kritisch studieren .... und dann?“ [Fo99] Forester, J. F.: The Deliberative Practitioner. Cambridge/London: MIT Press, 1999. [Ir98] Irrgang, B.: Praktische Ethik aus hermeneutischer Sicht. Paderborn: Schöningh, 1998. [Le84] Lévy-Bruhl, L.: L’Idée de Responsabilité. Paris: Hachette, 1884. [LK00] Lynch, W. T.; Kline, R.: Engineering Practice and Engineering Ethics. In: Science, Technology & Human Values, 25 (2) 2000, S. 195–225. [N02] National Institute of Standards and Technology: The Economic Impacts of Inadequate Infrastructure for Software Testing. Planning Report 02-3, 2002: http://www.nist.gov/director/prog-ofc/report02-3.pdf (gesehen 01.07.2003). [Ni87] Nietzsche, F.: Zur Genealogie der Moral. Leipzig: Verlag C.G. Naumann, 1887. [Nu90] Nussbaum, M.: Love’s Knowledge. New York: Oxford University Press, 1990. [Sc01] Schefe, P.: Ohnmacht der Ethik? Über professionelle Ethik als Immunisierungsstrategie. In: Informatik-Spektrum, 24 (3) 2001; S. 154-162. [We02] Weber, K.: Grenzen von Ethikcodizes. In: Kriterion, 2002 (15); S. 3-12.